Czy przedwczesna optymalizacja jest źródłem wszelkiego zła?

Przedwczesne mikro optymalizacje są źródłem wszelkiego zła, ponieważ mikro optymalizacje pomijają kontekst. Prawie nigdy nie zachowują się tak, jak są oczekiwane.

Jakie są dobre wczesne optymalizacje w kolejności ważności:

• optymalizacje architektoniczne (struktura aplikacji, sposób jej komponowania i warstwowania)
• optymalizacja przepływu danych (wewnątrz i na zewnątrz aplikacji)

Jakiś średni cykl rozwojowy optymalizacje:

• struktury danych, wprowadzenie nowych struktur danych, które mają lepszą wydajność lub niższe koszty w razie potrzeby
• algorytmy (teraz jest dobry czas, aby zacząć decydować między quicksort3 i heapsort ; -))

Niektóre optymalizacje końca cyklu rozwojowego

• znajdowanie hotpotów kodu (ciasnych pętli, które powinny być zoptymalizowane)
• profilowanie oparte na optymalizacji obliczeniowych części kodu
• mikro optymalizacje można wykonać teraz jako są one wykonywane w kontekście aplikacji, a ich wpływ można prawidłowo zmierzyć.

Nie wszystkie wczesne optymalizacje są złe, mikro optymalizacje są złe, jeśli są wykonywane w niewłaściwym czasie w cyklu życia projektu , ponieważ mogą negatywnie wpływać na architekturę, mogą negatywnie wpływać na początkową produktywność, mogą być nieistotne pod względem wydajności lub nawet mieć szkodliwy wpływ na koniec rozwoju z powodu różnych warunków środowiska.

Jeśli wydajność jest troska (i zawsze powinna być) zawsze myśl duży . Wydajność to szerszy obraz, a nie Takie rzeczy jak: Czy powinienem używać int czy long ?. Wybierz Top Down podczas pracy z wydajnością zamiast Bottom Up .

Optymalizacja bez pierwszego pomiaru jest prawie Zawsze przedwczesna.

Wierzę, że to prawda w tym przypadku, i prawda w ogólnym przypadku, jak również.

Optymalizacja jest " zła " jeśli powoduje:

• mniej czytelny kod
• znacznie więcej kodu
• mniej bezpieczny kod
• zmarnowany czas programisty

W Twoim przypadku wydaje się, że trochę czasu programisty było już spędzone, kod nie był zbyt skomplikowany (zgaduję z twojego komentarza, że wszyscy w zespole byliby w stanie zrozumieć), a kod jest trochę bardziej przyszłościowy (jest bezpieczny wątek teraz, jeśli rozumiem twój opis). Brzmi jak tylko trochę zła. :)

Dziwię się, że to pytanie ma 5 lat, a mimo to nikt nie opublikował więcej tego, co Knuth miał do powiedzenia, niż kilka zdań. Kilka akapitów otaczających słynny cytat wyjaśnia to całkiem dobrze. Artykuł, który jest cytowany, nazywa się " Structured Programming with go to Statements" i chociaż ma prawie 40 lat, dotyczy kontrowersji i ruchu programistycznego, który nie istnieje i zawiera przykłady w językach programowania, których wielu ludzi nigdy nie zna słyszałem o zaskakująco dużej ilości tego, co powiedział, nadal obowiązuje.

Oto większy cytat (ze strony 8 pdf, strona 268 w oryginale):

Poprawa szybkości z przykładu 2 do przykładu 2a wynosi tylko około 12%, a wiele osób uznałoby to za nieistotne. Konwencjonalna mądrość dzielona przez wielu dzisiejszych inżynierów oprogramowania wymaga ignorowania wydajności w małych; ale uważam, że jest to po prostu przesadna reakcja na nadużycia, które widzą praktykowane przez mądrzy i głupi programiści, którzy nie potrafią debugować ani utrzymywać swoich "zoptymalizowanych" programów. W uznanych dyscyplinach inżynierskich poprawa o 12%, łatwo uzyskana, nigdy nie jest uważana za marginalną; i uważam, że ten sam punkt widzenia powinien przeważać w inżynierii oprogramowania. Oczywiście nie zawracałbym sobie głowy tworzeniem takich optymalizacji przy jednorazowym zadaniu, ale jeśli chodzi o przygotowanie programów wysokiej jakości, nie chcę ograniczać się do narzędzi, które odmawiają mi takiej wydajności.

Jest bez wątpienia Graal efektywności prowadzi do nadużyć. Programiści tracą ogromne ilości czasu na myślenie lub martwienie się szybkością niekonkrytycznych części swoich programów, a te próby wydajności rzeczywiście mają silny negatywny wpływ podczas debugowania i konserwacji. My powinniśmy zapomnieć o małej wydajności, powiedzmy około 97% czasu: przedwczesna optymalizacja jest korzeniem wszelkiego zła.

Nie powinniśmy jednak rezygnować z naszych możliwości w tym krytyczne 3%. Dobry programista nie będzie popadał w samozadowolenie z powodu takiego rozumowania, będzie mądry, aby uważnie przyjrzeć się krytycznemu kodowi; ale dopiero po tym, jak kod ten zostanie zidentyfikowany. Często błędem jest osądzanie a priori, które części programu są naprawdę krytyczne, ponieważ uniwersalne doświadczenie programistów, którzy używali narzędzi pomiarowych, polegało na tym, że ich intuicyjne domysły zawodzą.

Kolejny dobry kawałek z poprzedniej strony:

Moje własne styl programowania oczywiście zmienił się w ciągu ostatniej dekady, zgodnie z trendami czasów (np. nie jestem już tak tricky, i używam mniej go to ' s), ale główna zmiana w moim stylu została spowodowana tym zjawiskiem pętli wewnętrznej. Teraz patrzę z bardzo żółtawym okiem na każdą operację w krytycznej pętli wewnętrznej, starając się zmodyfikować mój program i strukturę danych (jak w zmianie z przykładu 1 na przykład 2), tak aby niektóre operacje mogły zostać wyeliminowane. Przyczyny tego podejście polega na tym, że: a) nie trwa to długo, ponieważ wewnętrzna pętla jest krótka; b) wypłata jest prawdziwa; i c) mogę sobie pozwolić na to, aby być mniej wydajnym w innych częściach moich programów, które są bardziej czytelne i łatwiejsze do napisania i debugowania.

Często widziałem ten cytat używany, aby uzasadnić oczywiście zły kod lub kod, który, chociaż jego wydajność nie została zmierzona, prawdopodobnie może być wykonany szybciej dość łatwo, bez zwiększania rozmiaru kodu lub pogorszenia jego czytelności.

Ogólnie uważam, że wczesne mikro-optymalizacje mogą być złym pomysłem. Jednak makro-optymalizacje(takie jak wybór algorytmu o(log N) zamiast O(N^2)) są często warte zachodu i powinny być wykonane wcześnie, ponieważ pisanie O (N^2 może być marnotrawne) algorytmu, a następnie odrzucić go całkowicie na rzecz podejścia O (log N).

Zauważ, że słowa mogą być : jeśli algorytm O(N^2) jest prosty i łatwy do napisania, możesz wyrzucić go później bez większego poczucia winy, jeśli okaże się zbyt wolny. Ale jeśli oba algorytmy są podobnie złożone lub jeśli oczekiwane obciążenie jest tak duże, że już wiesz, że potrzebujesz szybszego, optymalizacja early jest solidną decyzją inżynierską, która zmniejszy całkowite obciążenie w długim czasie uciekaj.

Tak więc, ogólnie rzecz biorąc, myślę, że właściwym podejściem jest sprawdzenie, jakie są Twoje opcje, zanim zaczniesz pisać kod i świadomie wybierzesz najlepszy algorytm dla swojej sytuacji. Co najważniejsze, wyrażenie "przedwczesna optymalizacja jest źródłem wszelkiego zła" nie jest usprawiedliwieniem dla ignorancji. Twórcy kariery powinni mieć ogólne pojęcie o tym, ile kosztują wspólne operacje; powinni wiedzieć na przykład,

• że ciągi kosztują więcej niż liczby
• że dynamiczne języki są znacznie wolniejsze od języków typowanych statycznie
• zalety list tablicowych / wektorowych nad listami połączonymi i vice versa
• Kiedy używać hashtable, kiedy używać posortowanej mapy, a kiedy używać sterty
"Double " i" int "mają podobną wydajność na komputerach stacjonarnych (FP może być nawet szybszy), ale "double" może być sto razy wolniejszy na low-endowych urządzeniach mobilnych bez FPU;]}
• że przesyłanie danych przez internet jest wolniejsze niż dostęp do dysku twardego, dyski twarde są znacznie wolniejsze niż pamięć RAM, Pamięć RAM jest znacznie wolniejsza niż pamięć podręczna i rejestry L1, a operacje internetowe mogą blokować się w nieskończoność (i zawieść w dowolnym momencie).

A programiści powinni być zaznajomieni z zestawem narzędzi struktur danych i algorytmów, aby mogli łatwo korzystać z odpowiednich narzędzi do tego zadania.

Posiadanie dużej wiedzy i osobistego zestawu narzędzi pozwala na optymalizację niemal bez wysiłku. Wkładanie dużo wysiłku w optymalizację, która może być niepotrzebne jest złem (i przyznaję, że wpadłem w tę pułapkę nie raz). Ale jeśli optymalizacja jest tak łatwa, jak wybranie zestawu / hashtable zamiast tablicy lub przechowywanie listy liczb w podwójnym [] zamiast ciągu [], to dlaczego nie? Może się tu nie Zgadzam z Knuthem, nie jestem pewien, ale myślę, że mówił o optymalizacji niskiego poziomu, podczas gdy ja mówię o optymalizacji wysokiego poziomu.

Pamiętaj, że cytat pochodzi z 1974 roku. W 1974 roku komputery były powolność i moc obliczeniowa były drogie, co dało niektórym programistom tendencję do nadmiernej optymalizacji, linia po linii. Myślę, że Knuth naciskał na to. Nie mówił "nie martw się o występ w ogóle", bo w 1974 to byłaby tylko szalona rozmowa. Knuth wyjaśniał Jak optymalizować; krótko mówiąc, należy skupić się tylko na wąskich gardłach, a zanim to zrobisz, musisz wykonać pomiary, aby znaleźć wąskie gardła.

Zauważ, że nie możesz znaleźć wąskich gardeł, dopóki napisałeś program do pomiaru, co oznacza, że niektóre decyzje dotyczące wydajności muszą zostać podjęte, zanim cokolwiek istnieje do pomiaru. Czasami te decyzje są trudne do zmiany, jeśli je źle. Z tego powodu dobrze jest mieć ogólny obraz kosztów, dzięki czemu można podejmować rozsądne decyzje, gdy nie ma twardych danych.

Jak wcześnie zoptymalizować i jak bardzo martwić się o wydajność zależy od zadania. Pisząc skrypty, które uruchomisz tylko kilka czasy, martwiąc się o wydajność w ogóle jest zwykle kompletną stratą czasu. Ale jeśli pracujesz dla Microsoft lub Oracle i pracujesz nad biblioteką, która tysiące innych programistów będą używać na tysiące różnych sposobów, może się opłacić Optymalizacja, aby móc efektywnie obejmować wszystkie różnorodne przypadki użycia. Mimo to, potrzeba wydajności zawsze musi być zrównoważona z potrzebą czytelności, konserwacji, elegancji, rozciągliwości i tak dalej.

Osobiście, jak opisano w poprzednim wątku , nie wierzę, że wczesna optymalizacja jest zła w sytuacjach, w których wiesz, że trafisz na problemy z wydajnością. Na przykład piszę oprogramowanie do modelowania i analizy powierzchni, w którym regularnie zajmuję się dziesiątkami milionów podmiotów. Planowanie optymalnej wydajności na etapie projektowania jest znacznie lepsze niż późna optymalizacja słabego projektu.

Kolejną rzeczą do rozważenia jest to, jak Twoja aplikacja będzie skalowana w przyszłości. Jeśli rozważysz że Twój kod będzie miał długą żywotność, optymalizacja wydajności na etapie projektowania jest również dobrym pomysłem.

Z mojego doświadczenia wynika, że późna optymalizacja zapewnia skromne nagrody za wysoką cenę. Optymalizacja na etapie projektowania, poprzez wybór algorytmu i dostosowanie, jest znacznie lepsza. W zależności od profilera, aby zrozumieć, jak działa twój kod, nie jest świetnym sposobem na uzyskanie kodu o wysokiej wydajności, powinieneś o tym wiedzieć wcześniej.

W rzeczywistości dowiedziałem się, że przedwczesna nie-optymalizacja jest częściej źródłem wszelkiego zła.

Kiedy ludzie piszą oprogramowanie, początkowo będzie miało problemy, takie jak niestabilność, ograniczone funkcje, zła użyteczność i zła wydajność. Wszystko to zwykle zostaje naprawione, gdy oprogramowanie dojrzeje.

Wszystkie z nich, oprócz wydajności. Nikt nie dba o wydajność. Powód jest prosty: jeśli oprogramowanie ulegnie awarii, ktoś naprawi błąd i to wszystko, jeśli brakuje funkcji, ktoś zaimplementuje go i zrobione, jeśli oprogramowanie ma złą wydajność jest to w wielu przypadkach nie z powodu brakujących mikrooptymizacji, ale z powodu złego projektu i nikt nie będzie dotykać projektu oprogramowania. Nigdy.

Jeśli problem z oprogramowaniem jest to, że jest powolny, to dlatego, że jest bardzo powolny i można to naprawić tylko poprzez poprawę wydajności przez wiele. +10% po prostu nie przyspieszy powolnego oprogramowania. I zwykle nie otrzymasz więcej niż 10% przez późniejsze optymalizacje.

Jeśli więc wydajność jest ważna dla Twojego oprogramowania, powinieneś wziąć to pod uwagę od samego początku, przy jego projektowaniu, zamiast myśleć "o tak, jest powolne, ale możemy to poprawić później". Bo nie możesz!

Wiem, że nie naprawdę pasuje do twojego konkretnego przypadku, ale odpowiada na ogólne Pytanie " Czy przedwczesna optymalizacja jest naprawdę źródłem wszelkiego zła?"- z wyraźnym nie.

Każda optymalizacja, jak każda funkcja itp. musi być starannie zaprojektowany i wdrożony. A to obejmuje właściwą ocenę kosztów i korzyści. Nie Optymalizuj algorytmu, aby zapisać kilka cykli tu i ówdzie, gdy nie tworzy to mierzalnego przyrostu wydajności.

Jako przykład: możesz poprawić funkcję wydajność poprzez wbudowanie go, możliwe, że zapisanie kilku cykli, ale jednocześnie prawdopodobnie zwiększysz rozmiar pliku wykonywalnego, zwiększając szanse na błędy TLB i pamięci podręcznej kosztujące tysiące cykli lub nawet operacje przywoławcze, co całkowicie zabije wydajność. Jeśli nie rozumiesz tych rzeczy, Twoja "optymalizacja" może okazać się zła.

Głupia optymalizacja jest bardziej zła niż" przedwczesna " optymalizacja, ale obie są nadal lepsze niż przedwczesna nie-optymalizacja.

Istnieją dwa problemy z PO: po pierwsze, czas rozwoju jest wykorzystywany do pracy nieistotnej, która może być wykorzystana do napisania większej liczby funkcji lub naprawiania większej liczby błędów, a po drugie, fałszywe poczucie bezpieczeństwa, że kod działa wydajnie. PO często wiąże się z optymalizacją kodu, który nie będzie szyjką butelki, nie zauważając kodu, który będzie. "Przedwczesny" bit oznacza, że optymalizacja odbywa się przed zidentyfikowaniem problemu za pomocą odpowiednich pomiarów.

Tak w zasadzie, tak, brzmi to jak przedwczesna optymalizacja, ale niekoniecznie wycofałbym ją, chyba że wprowadza błędy - w końcu została zoptymalizowana(!)

Uważam, że Mike Cohn nazywa to "złoceniem" kodu - czyli spędzaniem czasu na rzeczach, które mogą być miłe, ale nie są konieczne.

P. S. "Złocenie" może być rodzajem funkcjonalności spec-wise. Gdy spojrzysz na kod, przybiera to formę niepotrzebnej optymalizacji, klas "przyszłościowych" itp.

Ponieważ nie ma problemu ze zrozumieniem kodu, to ten przypadek można uznać za wyjątek.

Ale ogólnie optymalizacja prowadzi do mniej czytelnego i mniej zrozumiałego kodu i powinna być stosowana tylko wtedy, gdy jest to konieczne. Prosty przykład - jeśli wiesz, że musisz posortować tylko kilka elementów-użyj BubbleSort. Ale jeśli podejrzewasz, że elementy mogą wzrosnąć i nie wiesz, jak bardzo, to optymalizacja za pomocą QuickSort (na przykład) nie jest zła, ale koniecznością. I to powinno być brane pod uwagę podczas projektowania programu.

Odkryłem, że problem z przedwczesną optymalizacją występuje głównie podczas ponownego pisania istniejącego kodu, aby był szybszy. Widzę, jak może być problem z napisaniem jakiejś zawiłej optymalizacji, ale przede wszystkim widzę przedwczesną optymalizację, która ma brzydką głowę w naprawianiu tego, co nie jest (wiadomo, że jest) zepsute.

A najgorszym tego przykładem jest to, że widzę kogoś, kto ponownie implementuje funkcje ze standardowej biblioteki. To wielka czerwona flaga. Kiedyś widziałem, jak ktoś wdraża niestandardowe procedury manipulacji łańcuchami, ponieważ obawiał się, że wbudowane polecenia są zbyt wolne.

Powoduje to, że kod jest trudniejszy do zrozumienia (zły) i spala dużo czasu na pracę, która prawdopodobnie nie jest przydatna (zły).

Z innej perspektywy, z mojego doświadczenia wynika, że większość programistów / programistów nie planuje sukcesu, a" prototyp " prawie zawsze staje się wydaniem 1.0. Mam doświadczenie z 4 osobnymi oryginalnymi produktami, w których elegancki, seksowny i wysoce funkcjonalny front-end (zasadniczo interfejs użytkownika) zaowocował szerokim przyjęciem i entuzjazmem użytkowników. W każdym z tych produktów problemy z wydajnością zaczęły pojawiać się w stosunkowo krótkim czasie (od 1 do 2 lat), szczególnie w większy, bardziej wymagający klienci zaczęli przyjmować produkt. Bardzo szybko wydajność zdominowała listę problemów, chociaż rozwój nowych funkcji zdominował listę priorytetów zarządzania. Klienci stawali się coraz bardziej sfrustrowani, ponieważ każde wydanie dodawało nowe funkcje, które brzmiały świetnie, ale były prawie niedostępne ze względu na problemy z wydajnością.

Tak więc, bardzo fundamentalne wady projektu i wdrożenia, które były niewielkie lub nie były przedmiotem zainteresowania w "proto-type", stały się głównymi przeszkodami w dłuższej perspektywie sukces produktów (i firm).

Twoje demo klienta może wyglądać i działać świetnie na Twoim laptopie z domami XML, SQL Express i wieloma buforowanymi danymi po stronie klienta. System produkcyjny prawdopodobnie zawiesi spalanie, jeśli odniesiesz sukces.

W 1976 roku wciąż debatowaliśmy nad optymalnymi sposobami obliczania pierwiastka kwadratowego lub sortowania dużej tablicy, a przysłowie Dona Knutha było skierowane na błąd skupiania się na optymalizacji tego rodzaju niskiej rutyny na początku projektu proces zamiast skupiać się na rozwiązaniu problemu, a następnie optymalizacji zlokalizowanych regionów kodu.

Gdy ktoś powtarza przysłowie jako wymówkę do nie pisania wydajnego kodu (C++, VB, T-SQL lub w inny sposób), lub do nieprawidłowego zaprojektowania magazynu danych, lub do nieuwzględnienia architektury pracy sieciowej, to IMO po prostu demonstrują bardzo płytkie zrozumienie prawdziwej natury naszej pracy. Ray

Przypuszczam, że to zależy od tego, jak zdefiniujesz "przedwczesny". Szybkie tworzenie funkcjonalności niskiego poziomu podczas pisania nie jest z natury złe. Myślę, że to nieporozumienie z cytatem. Czasami myślę, że ten cytat przydałby się z pewnymi kwalifikacjami. Powtórzę jednak komentarze m_pgladiatora dotyczące czytelności.

Odpowiedź brzmi: to zależy. Będę argumentować, że wydajność jest duża sprawa dla niektórych rodzajów pracy, takich jak złożone zapytania do bazy danych. W wielu innych przypadkach komputer spędza większość czasu na oczekiwaniu na wprowadzenie przez użytkownika, więc optymalizacja większości kodu jest w najlepszym wypadku stratą wysiłku, a w najgorszym odwrotną do zamierzonej.

W niektórych przypadkach można zaprojektować wydajność lub wydajność (postrzeganą lub rzeczywistą) - wybierając odpowiedni algorytm lub projektując interfejs użytkownika tak, aby pewne kosztowne operacje dzieje się na przykład w tle. W wielu przypadkach profilowanie lub inne operacje mające na celu określenie hotspotów przyniosą ci korzyść 10/90.

Jednym z przykładów tego mogę opisać jest model danych, który kiedyś zrobiłem dla systemu zarządzania sprawami sądowymi, który miał około 560 tabel w nim. Zaczęło się znormalizowane ("pięknie znormalizowane", jak to ujął konsultant z pewnej firmy big-5) i musieliśmy umieścić w nim tylko cztery pozycje denormalizowanych danych: {]}

• Jeden zmaterializowany pogląd na obsługa ekranu wyszukiwania

• Jedna tabela utrzymywana w trybie wyzwalania obsługuje inny ekran wyszukiwania, którego nie można było wykonać przy zmaterializowanym widoku.

• Jedna denormalizowana tabela raportowania (istniała tylko dlatego, że musieliśmy przyjmować raporty o przepustowości, gdy projekt hurtowni danych został zamknięty)

• Jedna tabela obsługi wyzwalacza dla interfejsu, który musiał wyszukiwać najnowsze z dość dużej liczby różnych zdarzeń w obrębie system.

Był to (w tym czasie) największy projekt J2EE w Australazji - ponad 100 lat czasu dewelopera - i miał 4 denormalizowane elementy w schemacie bazy danych, z których jeden tak naprawdę nie należał do niego.

Przedwczesna optymalizacja nie jest źródłem wszelkiego zła, to na pewno. Są jednak wady:

• inwestujesz więcej czasu podczas rozwoju
• inwestujesz więcej czasu testując to
• inwestujesz więcej czasu naprawiając błędy, których w innym przypadku nie byłoby

Zamiast przedwczesnej optymalizacji, można zrobić wczesne testy widoczności, aby sprawdzić, czy istnieje rzeczywista potrzeba lepszej optymalizacji.

Większość z tych, którzy stosują się do "PMO" (częściowy cytat, czyli), twierdzi, że optymalizacje muszą być oparte na pomiarach, a pomiary nie mogą być wykonywane aż do samego końca.

To także moje doświadczenie z rozwoju dużych systemów, że testowanie wydajności odbywa się na samym końcu, jak rozwój zbliża się do końca.

Gdybyśmy podążali za "radami" tych ludzi, wszystkie systemy byłyby potwornie powolne. Będą drogie, ponieważ ich potrzeby sprzętowe są znacznie większe niż pierwotnie zakładano.

Od dawna zalecam wykonywanie testów wydajności w regularnych odstępach czasu w procesie rozwoju: będzie to wskazywać zarówno obecność nowego kodu (gdzie wcześniej nie było), jak i stan istniejącego kodu.

• wydajność nowo zaimplementowanego kodu można porównać z istniejącego, podobnego kodu. "Wyczucie" wydajności nowego kodu zostanie ustalona w czasie.
• Jeśli istniejący kod nagle zniknie rozumiesz, że coś stało się i można to zbadać od razu, nie (dużo) później, gdy wpływa na cały system.

Innym pomysłem pet jest instrumentowanie oprogramowania na poziomie bloku funkcyjnego. Gdy system wykonuje, gromadzi informacje o czasie wykonywania bloków funkcyjnych. Podczas aktualizacji systemu można określić, jakie bloki funkcyjne działają tak, jak we wcześniejszej wersji i te, które uległy pogorszeniu. Na ekranie oprogramowania dane wydajności można uzyskać z menu Pomoc.

Zobacz Ten świetny artykuł o tym, co PMO może oznaczać, a co nie.